Python API vārteja: pakalpojumu tīkla ieviešana mūsdienu arhitektūrām

Mūsdienu strauji mainīgajā digitālajā vidē mikropakalpojumu arhitektūras ir kļuvušas par normu mērogojamu, noturīgu un uzturamu lietojumprogrammu veidošanai. Šo arhitektūru pamatā ir nepieciešamība pēc efektīvas un drošas saziņas starp pakalpojumiem. Tieši šeit savu lomu spēlē API vārtejas un pakalpojumu tīkli. Šis raksts pēta, kā izveidot uz Python balstītu API vārteju un integrēt to ar pakalpojumu tīklu, nodrošinot stabilu risinājumu mikropakalpojumu saziņas pārvaldībai globālā kontekstā.

API vārteju un pakalpojumu tīklu izpratne

Kas ir API vārteja?

API vārteja darbojas kā vienots ieejas punkts visiem klientu pieprasījumiem uz mikropakalpojumu aizmuguri. Tā veic tādus uzdevumus kā:

• Maršrutēšana: Pieprasījumu novirzīšana uz atbilstošo mikropakalpojumu.
• Autentifikācija un autorizācija: Klienta identitātes pārbaude un nepieciešamo atļauju nodrošināšana.
• Ātruma ierobežošana: Novēršana ļaunprātīgas izmantošanas un pakalpojumu taisnīgas lietošanas nodrošināšana.
• Pieprasījumu transformācija: Pieprasījumu modificēšana pirms to nosūtīšanas uz aizmuguri.
• Atbilžu apvienošana: Atbilžu apvienošana no vairākiem mikropakalpojumiem vienā atbildē.
• Kešatmiņa: Latences samazināšana un veiktspējas uzlabošana.

Iedomājieties to kā izsmalcinātu recepcionistu jūsu lietojumprogrammai, kas apstrādā visu ienākošo datplūsmu un nodrošina, ka tā droši un efektīvi nokļūst pareizajā vietā. Piemēram, mobilā lietojumprogramma Austrālijā var nosūtīt pieprasījumu uz API vārteju, kas pēc tam novirza to uz cenu noteikšanas pakalpojumu, kas atrodas Singapūrā, un inventāra pakalpojumu Vācijā, apvienojot rezultātus pirms to atgriešanas lietotājam.

Kas ir pakalpojumu tīkls?

Pakalpojumu tīkls ir infrastruktūras slānis, kas apstrādā pakalpojumu savstarpējo saziņu mikropakalpojumu arhitektūrā. Tas nodrošina tādas funkcijas kā:

• Pakalpojumu atklāšana: Automātiska pakalpojuma pieejamo instanču atrašana.
• Datplūsmas pārvaldība: Datplūsmas plūsmas kontrole starp pakalpojumiem, ieskaitot slodzes balansēšanu, maršrutēšanu un ķēdes pārtraukšanu.
• Novērojamība: Ieskatu nodrošināšana par pakalpojumu veiktspēju un stāvokli.
• Drošība: Saziņas šifrēšana starp pakalpojumiem un drošības politiku ieviešana.

Pakalpojumu tīkls parasti sastāv no kontroles plaknes (piemēram, Istio) un datu plaknes (piemēram, Envoy). Datu plakne pārtver visu pakalpojumu savstarpējo saziņu un piemēro kontroles plaknes definētās politikas. Iedomājieties neredzamu kurjeru tīklu, kas apstrādā visu iekšējo saziņu, nodrošinot ziņojumu drošu, uzticamu un efektīvu piegādi. Pakalpojumu tīkls pēc noklusējuma nodrošina nulles uzticības tīklošanu – katrs pakalpojums autentificē katru citu pakalpojumu, neatkarīgi no to atrašanās vietas. Tas ir īpaši svarīgi starptautiskās korporācijās, kuru pakalpojumi ir izplatīti dažādos ģeogrāfiskos reģionos.

Kāpēc apvienot API vārteju un pakalpojumu tīklu?

Lai gan gan API vārtejas, gan pakalpojumu tīkli risina mikropakalpojumu saziņas problēmas, tie darbojas dažādos slāņos un risina dažādas problēmas. API vārteja koncentrējas uz ārējās datplūsmas pārvaldību, savukārt pakalpojumu tīkls koncentrējas uz iekšējās datplūsmas pārvaldību. Abu apvienošana nodrošina visaptverošu risinājumu mikropakalpojumu saziņas nodrošināšanai, pārvaldībai un novērošanai gan klastera iekšienē, gan ārpus tā.

Piemēram, apsveriet e-komercijas platformu. API vārteja apstrādā pieprasījumus no tīmekļa un mobilajām lietojumprogrammām, autentificējot lietotājus, piemērojot ātruma ierobežojumus un novirzot pieprasījumus uz atbilstošajiem aizmugures pakalpojumiem. Pakalpojumu tīkls pārvalda saziņu starp aizmugures pakalpojumiem, nodrošinot drošu un uzticamu saziņu starp produktu katalogu, pasūtījumu pārvaldību un maksājumu apstrādes pakalpojumiem. API vārteja var izmantot ārējos autentifikācijas pakalpojumus, piemēram, Okta vai Auth0, savukārt pakalpojumu tīkls nodrošina drošu saziņu starp iekšējiem pakalpojumiem, izmantojot savstarpēju TLS (mTLS).

Python API vārtejas izveide

Python ar savu bagātīgo bibliotēku un ietvaru ekosistēmu ir lieliska izvēle API vārteju veidošanai. Mēs izmantosim ietvaru kombināciju, lai izveidotu mērogojamu un uzturamu vārteju.

Ietvaru izvēle

• FastAPI: Mūsdienīgs, augstas veiktspējas tīmekļa ietvars API veidošanai. FastAPI nodrošina automātisku datu validāciju, serializāciju un dokumentācijas ģenerēšanu.
• Uvicorn: ASGI serveris asinhronu Python lietojumprogrammu palaišanai.
• Requests: Bibliotēka HTTP pieprasījumu veikšanai uz aizmugures pakalpojumiem. Sarežģītākiem scenārijiem apsveriet `httpx` izmantošanu, kas nodrošina asinhronu atbalstu.
• PyJWT: Bibliotēka darbam ar JSON tīmekļa žetoniem (JWT) autentifikācijai.

Projekta struktūra

api_gateway/
├── main.py        # Galvenais lietojumprogrammas fails
├── config.py      # Konfigurācijas iestatījumi
├── routes.py      # API maršrutēšanas definīcijas
├── auth.py        # Autentifikācijas loģika
├── utils.py       # Utilitāras funkcijas
└── requirements.txt # Projekta atkarības

Piemēra kods: main.py

from fastapi import FastAPI, Depends, HTTPException, Request
from fastapi.responses import JSONResponse
import uvicorn
import requests
import jwt
from config import settings
from auth import verify_jwt
from routes import router

app = FastAPI()
app.include_router(router)

@app.middleware("http")
async def add_process_time_header(request: Request, call_next):
    response = await call_next(request)
    return response

if __name__ == "__main__":
 uvicorn.run(app, host="0.0.0.0", port=8000)

Piemēra kods: routes.py

from fastapi import APIRouter, Depends, HTTPException, Request
from fastapi.responses import JSONResponse
import requests
import jwt
from config import settings
from auth import verify_jwt

router = APIRouter()

@router.get("/products/{product_id}")
async def get_product(product_id: int, request: Request, is_authenticated: bool = Depends(verify_jwt)):
  # Pārsūtīt pieprasījumu uz produktu pakalpojumu
  product_service_url = f"{settings.product_service_url}/products/{product_id}"

  try:
      response = requests.get(product_service_url)
      response.raise_for_status()  # Izmest HTTPError par sliktām atbildēm (4xx vai 5xx)
      return response.json()
  except requests.exceptions.RequestException as e:
      raise HTTPException(status_code=500, detail=f"Kļūda saziņā ar produktu pakalpojumu: {e}")

@router.post("/orders")
async def create_order(request: Request, is_authenticated: bool = Depends(verify_jwt)):
 # Pārsūtīt pieprasījumu uz pasūtījumu pakalpojumu
 order_service_url = f"{settings.order_service_url}/orders"
 body = await request.json()

 try:
  response = requests.post(order_service_url, json=body)
  response.raise_for_status()
  return response.json()
 except requests.exceptions.RequestException as e:
  raise HTTPException(status_code=500, detail=f"Kļūda saziņā ar pasūtījumu pakalpojumu: {e}")

Piemēra kods: auth.py

from fastapi import HTTPException, Depends, Header
import jwt
from config import settings
from typing import Optional

async def verify_jwt(authorization: Optional[str] = Header(None)) -> bool:
 if not authorization:
  raise HTTPException(status_code=401, detail="Autentifikācijas galvene ir nepieciešama")

 try:
  token = authorization.split(" ")[1]
  jwt.decode(token, settings.jwt_secret, algorithms=[settings.jwt_algorithm])
  return True
 except jwt.ExpiredSignatureError:
  raise HTTPException(status_code=401, detail="Žetons ir beidzies")
 except jwt.InvalidTokenError:
  raise HTTPException(status_code=401, detail="Nederīgs žetons")

Piemēra kods: config.py

import os
from typing import Optional
from pydantic import BaseSettings

class Settings(BaseSettings):
 product_service_url: str = os.getenv("PRODUCT_SERVICE_URL", "http://localhost:8001")
 order_service_url: str = os.getenv("ORDER_SERVICE_URL", "http://localhost:8002")
 jwt_secret: str = os.getenv("JWT_SECRET", "secret")
 jwt_algorithm: str = os.getenv("JWT_ALGORITHM", "HS256")

 settings = Settings()

Konfigurācija

Saglabājiet konfigurācijas iestatījumus, piemēram, aizmugures pakalpojumu URL un autentifikācijas atslēgas, atsevišķā konfigurācijas failā (piemēram, `config.py`). Izmantojiet vides mainīgos, lai konfigurētu dažādas vides (izstrāde, testēšana, ražošana).

Autentifikācija

Ieviesiet autentifikāciju, izmantojot JWT. API vārteja pārbauda JWT pirms pieprasījuma pārsūtīšanas uz aizmugures pakalpojumu. Šī pieeja veicina drošību un decentralizāciju. Lielākām organizācijām apsveriet integrāciju ar identitātes nodrošinātāju, piemēram, Keycloak vai Azure AD. Tas var centralizēt autentifikācijas un autorizācijas politikas.

Maršrutēšana

Definējiet maršrutus atsevišķā failā (piemēram, `routes.py`). Izmantojiet FastAPI maršrutētāja funkcionalitāti, lai kartētu ienākošos pieprasījumus uz atbilstošajiem aizmugures pakalpojumiem. Ieviesiet maršrutēšanu, pamatojoties uz pieprasījuma ceļu, HTTP metodi un galvenēm.

Piemērs: API vārtejas dockerizācija

Izveidojiet `Dockerfile`, lai iepakotu API vārteju konteinerā.

FROM python:3.9-slim-buster

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Pakalpojumu tīkla integrācija

Python API vārtejas integrēšana ar pakalpojumu tīklu, piemēram, Istio, uzlabo drošību, novērojamību un datplūsmas pārvaldību. Mēs koncentrēsimies uz to, kā konfigurēt Istio, lai pārvaldītu datplūsmu, kas plūst caur API vārteju.

Istio instalēšana

Pirms turpināt, pārliecinieties, vai Istio ir instalēts jūsu Kubernetes klasterī. Instalēšanas norādījumus skatiet oficiālajā Istio dokumentācijā. Daudzi mākoņpakalpojumu nodrošinātāji, piemēram, AWS, Google Cloud un Azure, piedāvā pārvaldītus Istio pakalpojumus, kas vienkāršo izvietošanu un pārvaldību.

Sidecar injekcija

Istio izmanto sidecar starpniekserveri (Envoy), lai pārtvertu visu datplūsmu uz un no pakalpojuma. Lai iespējotu Istio API vārtejai, jums ir jāievada sidecar starpniekserveris API vārtejas podā. Tas parasti tiek darīts, pievienojot anotāciju poda izvietošanai:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-gateway
  labels:
    app: api-gateway
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api-gateway
  template:
    metadata:
      labels:
        app: api-gateway
      annotations:
        sidecar.istio.io/inject: "true" # Iespējot Istio sidecar injekciju
    spec:
      containers:
      - name: api-gateway
        image: your-api-gateway-image:latest
        ports:
        - containerPort: 8000

Virtuālie pakalpojumi un vārtejas

Istio izmanto virtuālos pakalpojumus un vārtejas, lai pārvaldītu datplūsmas maršrutēšanu. Vārteja definē datplūsmas ieejas punktu tīklā, savukārt virtuālais pakalpojums definē, kā datplūsma tiek maršrutēta uz pakalpojumiem tīklā.

Istio vārtejas izveide

Definējiet Istio vārteju, lai API vārteju eksponētu ārējai datplūsmai.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: api-gateway-gateway
spec:
  selector:
    istio: ingressgateway # Izmantojiet Istio noklusējuma ieejas vārteju
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*" # Aizstāt ar savu domēnu

Virtuālā pakalpojuma izveide

Definējiet virtuālo pakalpojumu, lai maršrutētu datplūsmu no vārtejas uz API vārtejas pakalpojumu.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: api-gateway-virtualservice
spec:
  hosts:
  - "*" # Aizstāt ar savu domēnu
  gateways:
  - api-gateway-gateway
  http:
  - route:
    - destination:
        host: api-gateway # Pakalpojuma nosaukums Kubernetes
        port:
          number: 8000 # Ports, kurā klausās API vārteja

Datplūsmas pārvaldība ar Istio

Istio nodrošina jaudīgas datplūsmas pārvaldības iespējas, piemēram:

• Slodzes balansēšana: Datplūsmas sadale starp vairākām pakalpojuma instancēm. Istio atbalsta dažādus slodzes balansēšanas algoritmus, tostarp apaļo, mazāk savienojumu un konsekventu hešošanu.
• Datplūsmas sadale (kanārijas izvietošana): Pakāpeniska jaunu pakalpojuma versiju izvietošana, nosūtot nelielu datplūsmas procentu jaunajai versijai. Tas ļauj jums testēt jaunas funkcijas ražošanā, neietekmējot visus lietotājus.
• Ķēdes pārtraukšana: Kaskādes kļūdu novēršana, automātiski pārtraucot datplūsmu uz neveselīgiem pakalpojumiem.
• Kļūdu ievadīšana: Kavējumu vai kļūdu ievadīšana datplūsmā, lai pārbaudītu jūsu lietojumprogrammas noturību.

Piemērs: Kanārijas izvietošana ar Istio

Lai veiktu kanārijas izvietošanu, jūs varat konfigurēt Istio nosūtīt nelielu datplūsmas procentu (piemēram, 10%) uz jauno API vārtejas versiju.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: api-gateway-virtualservice
spec:
  hosts:
  - "*" # Aizstāt ar savu domēnu
  gateways:
  - api-gateway-gateway
  http:
  - route:
    - destination:
        host: api-gateway # Versija 1
        port:
          number: 8000
        weight: 90
    - destination:
        host: api-gateway-v2 # Versija 2 (Kanārija)
        port:
          number: 8000
        weight: 10

Novērojamība

Monitorings un žurnālēšana ir kritiski svarīgi, lai izprastu jūsu API vārtejas un aizmugures pakalpojumu veiktspēju un stāvokli. Ieviesiet visaptverošu novērojamību, izmantojot tādus rīkus kā:

• Prometheus: Monitoringa sistēma metrikas vākšanai un uzglabāšanai. Istio integrējas ar Prometheus, lai nodrošinātu metriku par pakalpojumu datplūsmu, latentumu un kļūdām.
• Grafana: Datu vizualizācijas rīks paneļu izveidei, lai uzraudzītu jūsu lietojumprogrammu.
• Jaeger: Izkliedēta izsekošanas sistēma pieprasījumu izsekošanai, kad tie plūst caur jūsu mikropakalpojumiem. Istio var automātiski ģenerēt izsekošanu visai pakalpojumu savstarpējai saziņai.
• Fluentd/Elasticsearch/Kibana (EFK Stack): Žurnālēšanas steks žurnālu vākšanai, glabāšanai un analīzei.

Istio telemetrija

Istio automātiski vāc telemetrijas datus par pakalpojumu datplūsmu, ieskaitot metriku, žurnālus un izsekošanu. Šos datus varat izmantot, lai uzraudzītu jūsu API vārtejas un aizmugures pakalpojumu veiktspēju un stāvokli. Konfigurējiet Istio, lai eksportētu telemetrijas datus uz Prometheus, Grafana un Jaeger.

API vārtejas specifiskā metrika

Papildus Istio telemetrijas datiem jums vajadzētu vākt arī API vārtejas specifisko metriku, piemēram:

• Pieprasījumu ātrums: Pieprasījumu skaits sekundē.
• Atbildes laiks: Vidējais laiks, kas nepieciešams pieprasījuma apstrādei.
• Kļūdu biežums: Pieprasījumu procentuālā daļa, kas beidzas ar kļūdu.
• Autentifikācijas veiksmes/neveiksmes līmenis: Veiksmīgu un neveiksmīgu autentifikācijas mēģinājumu skaits.
• Kešatmiņas trāpījumu biežums: Pieprasījumu procentuālā daļa, kas tiek apkalpoti no kešatmiņas.

Drošības apsvērumi

Drošība ir vissvarīgākā, veidojot API vārteju. Apsveriet šādus drošības pasākumus:

• Autentifikācija un autorizācija: Ieviesiet stabilus autentifikācijas un autorizācijas mehānismus, lai aizsargātu jūsu aizmugures pakalpojumus. Izmantojiet JWT, OAuth 2.0 vai citus nozares standarta protokolus.
• Ievades validācija: Validējiet visus ienākošos pieprasījumus, lai novērstu injekcijas uzbrukumus.
• Ātruma ierobežošana: Ieviesiet ātruma ierobežošanu, lai novērstu ļaunprātīgu izmantošanu un pakalpojumu atteikuma uzbrukumus.
• TLS šifrēšana: Šifrējiet visu saziņu starp API vārteju un aizmugures pakalpojumiem, izmantojot TLS. Istio nodrošina automātisku TLS šifrēšanu, izmantojot savstarpēju TLS (mTLS).
• Tīmekļa lietojumprogrammu ugunsmūris (WAF): Izmantojiet WAF, lai aizsargātu pret bieži sastopamiem tīmekļa lietojumprogrammu uzbrukumiem, piemēram, SQL injekciju un starpvietņu skriptošanu (XSS).
• Regulāras drošības pārbaudes: Veiciet regulāras drošības pārbaudes, lai identificētu un novērstu ievainojamības.

Savstarpējais TLS (mTLS) ar Istio

Istio var automātiski ieviest mTLS visai pakalpojumu savstarpējai saziņai, nodrošinot, ka visa saziņa tiek šifrēta un autentificēta. Tas nodrošina spēcīgu drošības slāni pret noklausīšanos un manipulācijām.

Papildu tēmas

GraphQL vārteja

Tā vietā, lai izmantotu REST API, apsveriet GraphQL izmantošanu efektīvākai datu iegūšanai. Ieviesiet GraphQL vārteju, izmantojot tādas bibliotēkas kā Graphene un Ariadne. GraphQL ļauj klientiem pieprasīt tikai nepieciešamos datus, samazinot pārmērīgu datu iegūšanu un uzlabojot veiktspēju.

gRPC vārteja

Augstas veiktspējas saziņai starp pakalpojumiem apsveriet gRPC izmantošanu. Ieviesiet gRPC vārteju, lai gRPC pakalpojumus eksponētu ārējiem klientiem. Izmantojiet tādus rīkus kā grpc-gateway, lai ģenerētu RESTful API no gRPC definīcijām.

Serverless API vārteja

Izvietojiet savu API vārteju kā serverless funkciju, izmantojot tādas platformas kā AWS Lambda, Google Cloud Functions vai Azure Functions. Serverless API vārtejas piedāvā mērogojamību, izmaksu efektivitāti un samazinātas ekspluatācijas izmaksas. Piemēram, API vārteju var integrēt ar AWS Lambda funkcijām, kas rakstītas Python, lai apstrādātu pieprasījumus. Šī serverless pieeja var ievērojami samazināt infrastruktūras izmaksas.

Secinājums

Python API vārtejas izveide ar pakalpojumu tīkla integrāciju nodrošina stabilu un mērogojamu risinājumu mikropakalpojumu saziņas pārvaldībai. Apvienojot API vārteju un pakalpojumu tīklu stiprās puses, jūs varat panākt uzlabotu drošību, novērojamību un datplūsmas pārvaldību. Šī arhitektūra ir piemērota modernām, mākoņdatošanas lietojumprogrammām, kurām nepieciešama augsta pieejamība, mērogojamība un drošība. Atcerieties ņemt vērā jūsu specifiskās prasības un izvēlēties rīkus un tehnoloģijas, kas vislabāk atbilst jūsu vajadzībām. Piemēram, mazāks uzņēmums varētu dot priekšroku Kong kā API vārtejai un Linkerd kā pakalpojumu tīklam to salīdzinošās lietošanas ērtības dēļ, savukārt lielāks uzņēmums varētu izvēlēties Istio un pielāgotu Python API vārteju, lai nodrošinātu precīzu kontroli pār katru savas arhitektūras aspektu. Pareizu rīku izvēle un rūpīga iepriekš minēto drošības apsvērumu ieviešana ir panākumu priekšnoteikums. Turklāt nepārtraukta uzraudzība un pielāgošanās ir ļoti svarīga, lai uzturētu stabilu un drošu API vārteju nepārtraukti mainīgajā tehnoloģiskajā vidē.